View figure.
The Network Utility provides host connectivity through an ESCON channel or parallel channel. It enables the Network Utility to function as a gateway from the host to other networks.
There are three interfaces from host software to a Network Utility.
The first interface is the 8232-compatible support, called LAN Channel Station (LCS). This interface defines a number of commands for direct LAN connection and a blocking and deblocking structure. LAN-ready frames are transmitted from the host to the virtual LAN adapters and conversely. This interface is used by TCP/IP for VM and MVS and AIX/370.
The second interface is the Link Services Architecture (LSA) support, which is accessed in the host through VTAM.
The LSA support is a control interface to allow VTAM to use the Logical Link Control (LLC) portion of the Data Link Control (DLC) layer of the SNA stack. Included is access to LLC Type 1 (connectionless) and LLC Type 2 (connection oriented) data transport. This interface is used by VTAM for both SNA subarea and APPN ISR and HPR data transport.
The third interface is the Multi-Path Channel (MPC+) support, which is accessed in the host through VTAM. The MPC+ support is a protocol layer that allows multiple read and write subchannels to be treated as a single transmission group between the host and channel attached devices. This interface is used by OS/390 for APPN HPR, TCP/IP, and HPDT UDP data transport. Note that the Channel does not support MPC+ subchannel groups which are shared over more than one physical channel interface.
The Network Utility can support 64 ESCON subchannels, in any combination of LCS subchannel pairs, LSA subchannels, and MPC+ groups. This allows a maximum of 32 LCS virtual LAN adapters, or 32 LSA virtual LAN adapters, or 32 MPC+ groups (an MPC+ group must include at least one read subchannel and one write subchannel).
LSA and LCS virtual LAN adapters emulate a Token-Ring, FDDI, or Ethernet interface for communications with the host. This does not restrict the format of the remote network interface. It is intended only to maintain the existing host interfaces of the 3172 Interconnect Controller, to eliminate host support changes.
Each virtual LAN adapter or MPC+ group can support only one host connection type (LCS/LSA/MPC+). LSA and LCS subchannels can support multiple virtual LAN adapters, for example, one Token-Ring interface and one Ethernet interface. There is no perceived value to supporting multiple virtual LAN adapters of the same type on a single subchannel or pair, but configuration will not preclude it.
The host LAN gateway function allows host applications to communicate with LAN-based workstations. The two main host applications supported by the host LAN gateway function are TCP/IP and VTAM. These applications encapsulate LAN frames into channel control words (CCWs) for transport across the channel. This is also referred to as "blocking", because a CCW consists of a block of LAN frames sent as a single logical unit. The CCW is then "deblocked" by the receiver into individual frames.
Much of the Network Utility LAN gateway function is based on the 3172 Interconnect Controller Program (ICP). Even though there are differences in the 3172 ICP gateway function and the Network Utility Channel function, the hardware and software interfaces between the host and the Network Utility Channel are the same as the interfaces between the host and the 3172 ICP (except for the IP routing support provided within the Network Utility). To preserve the software interface, it is necessary for the Network Utility to create the appearance of a LAN adapter so that the host application still believes it is communicating with a real LAN.
The ESCON channel interface is divided into 256 logical addresses (inaccurately but consistently referred to as "subchannels" for historical reasons). Each host application interface uses one or more subchannels to connect the host application to the Network Utility. Through configuration, each subchannel is assigned a unique relative index, which may or may not match its actual logical address. The ESCON channel may be shared by multiple applications on multiple hosts, but each host application will have dedicated use of its subchannels. (This is not strictly true for MPC+, as explained later, but the statement applies at the MPC+ level; MPC+ subchannels cannot be shared with non-MPC+ applications.) The Network Utility supports up to 64 subchannels at a time.
Network Utility supports three channel protocols, corresponding to the three host software interfaces discussed above. Each protocol uses its subchannels differently, and a subchannel can support only one protocol at a time. The channel protocols supported are LAN Channel Station (LCS), Link Services Architecture (LSA) and Multi-Path Channel (MPC+).
LCS is a channel protocol supported by TCP/IP applications in the host. Each application defines a consecutive pair of subchannels, one for TCP/IP to read from the channel, and one for TCP/IP to write to the channel. The LCS interface allows LAN MAC frames to be transported over the channel, and provides a command interface to activate, deactivate, and query the LAN interfaces. Each MAC frame has a header that identifies the virtual LAN adapter destination of the frame.
LSA is an interface to support SNA traffic over the channel. Each LSA path is a single bidirectional subchannel between the host application and the Network Utility. The host software (VTAM) issues a read command immediately following each write command to retrieve data from the channel. The Network Utility also issues an Attention command when it has something for the host application to read. LSA has a command interface which allows VTAM to open Service Access Points (SAPs) to communicate with downstream workstations using the IEEE 802.2 logical link control (LLC) interface. The channel blocking/deblocking mechanism for LSA subchannels is the same as for LCS subchannel pairs.
MPC+ is a data link control (DLC) interface for the channel. Each MPC+ path consists of one or more read subchannels and one or more write subchannels, bound together to form a transmission group. MPC+ transmission groups which span more than one physical ESCON channel are not supported in this release. VTAM and the Network Utility exchange XIDs to identify the number and direction of subchannels at initialization, and then each frame has a header to indicate the sending and receiving applications.
The host channel interface packages control and data frames in blocks of up to 32 KB (36 KB for MPC+). The format of data blocks is different for MPC+ and non-MPC+ host applications. LSA and LCS blocks consist of one or more contiguous frames, each with a header that identifies the destination device by its LAN type and LAN number. MPC+ blocks contain one or more "discontiguous" frames, with the first 4 KB of the block containing MPC+ PDU headers and offsets of application data, which is stored in the last 32 KB of the block. MPC+ groups are identified by a "LAN type" and "LAN number" as well for implementation consistency.
A block of data is transmitted either when it is filled, or when the block delay timer (which determines how long the adapter waits for the block to fill before transmitting) expires. The process of receiving a block of data and forwarding the individual frames to the device driver is called "deblocking."
First, a little history: the 3172 Interconnect Control Program (on which the Network Utility is partially based) transferred frames from a host channel to one or more LANs. In its configuration, each subchannel was connected to one or more LAN device drivers. Data from the host was received by a deblocker, which would distribute the frames to one of the LAN adapters based on the LAN Type and LAN Number contained in the frame header. If a host application needed access to multiple LAN adapters, the configuration file would contain one entry for each LAN adapter.
In the Network Utility, instead of each subchannel being connected to one or more real LAN adapters, all of the subchannels are connected to the Base Net Handler, which is in turn connected to one or more virtual net handlers. Each virtual net handler supports one of the three channel protocols (LSA/LCS/MPC+) and sends and receives frames with one of the protocol applications (LLC/IP/APPN), which sends the data to another net handler representing a network connection. There may or may not be any real LAN adapters connected to the Network Utility.
To preserve the existing host interfaces, the Network Utility takes on the appearance of multiple LAN adapters for LSA and LCS connections. Based on configuration parameters, the Virtual net handlers register with the appropriate protocols as either Token-Ring, Ethernet, or FDDI adapters. The Base Net Handler allows the host to activate and deactivate this "virtual LAN adapter" in the same way it controls the 3172's real LAN adapters. Each virtual LAN adapter has its own MAC address, which allows the Network Utility to appear to the host as one or more LAN adapters on an actual local area network.
A single subchannel (or pair) can be connected to one or more virtual LAN adapters. This is necessary to allow a single host application to communicate with different types of LANs (Token-Ring, Ethernet, FDDI) over the same subchannel. LAN-bound frames are directed to the correct destination by the LAN Type and LAN Number in the frame header.
However, the inverse is true only for LSA connections. A single LCS virtual LAN adapter can be connected to only one subchannel. This restriction improves data throughput by allowing host-bound frames to be directed to the correct subchannel by the virtual net handler, without forcing the net handler to examine the MAC address or IP address of each host-bound frame. Multiple VTAMs can share a single LSA net handler if each opens a SAP with a unique number. This cannot be done for the LCS net handler because all TCP/IP traffic uses the multiprotocol SAP number 'AA'x. See Figure 14-1.
Figure 14-1. LAN-to-Subchannel Configuration
SC1
| SC1 SC2 SC3 SC4
*------*---*---*-------* | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | *-----*--*--*-----*
LAN1 LAN2 LAN3 LAN4 |
LAN1
YES NO!
(LSA only)
|
MPC+ does not use the virtual LAN adapter concepts common to both LSA and LCS interfaces, because MPC+ does not support a LAN gateway appearance for the Network Utility. The equivalent interface for MPC+ is the MPC+ group. An MPC+ group is a set of ESCON subchannels configured to act as a single data pipe between the host and Network Utility. An MPC+ group consists of at least one "read" subchannel and at least one "write" subchannel. Any number of subchannels may be designated as read or write, and multiple MPC+ groups may be defined, subject to a maximum of 64 total subchannels per Network Utility.
Data may be sent over any or all of the active subchannels in an MPC+ group. The MPC+ endpoint is responsible for maintaining data order over a group. The number of subchannels is fixed when the MPC+ group is defined.
MPC+ groups are identified in the microcode using the same "LAN type" and "LAN number" designation as virtual LAN adapters. As frames are deblocked by the microcode, each frame is given a "LAN type" of MPC+ and a "LAN number" that corresponds to the MPC+ group associated with the subchannel it was received on. This allows the microcode and net handler to process MPC+ frames in a manner consistent with LSA and LCS frames.
LLC Loopback is an extension of the virtual LAN adapter concept to allow VTAM connections with the APPN and DLSw functions in the Network Utility. To establish an SNA connection, the LSA interface creates an LLC connection between itself and the remote device across the LAN using IEEE 802.2 frames. See Figure 14-2.
Figure 14-2. Normal LLC Connection
*------*
| VTAM |
*--*---*
|
| LSA primitive
|
*-V---* *--------*
| LSA | | Remote |
*--*--* | Appl |
| *----^---*
| LLC command | LLC notification
| |
*--V--* *--*--*
| LLC *----------------------> LLC |
*-----* 802.2 frame *-----*
|
LLC Loopback allows the Network Utility to communicate directly with other LLC users (APPN and DLSw) in the Network Utility. Instead of turning LLC commands from LSA into 802.2 frames, they are converted into LLC notifications and sent to the appropriate LLC user. See Figure 14-3.
Figure 14-3. LLC Loopback Connection
*------*
| VTAM |
*---*--*
|
| LSA primitive
|
*--V--* *------------*
| LSA | | APPN/DLSW |
*--*--* *------^-----*
| |
| LLC command | LLC notification
| |
*--V--------------------------*-------*
| LLC Loopback |
*-------------------------------------*
|
LLC Loopback allows the APPN Network Node in Network Utility to act as the adjacent node to VTAM. It also permits VTAM to connect to remote devices and applications using Data Link Switching without requiring changes to VTAM's LSA support, because the loopback connection appears the same as a normal LLC connection to VTAM.
This section describes four sample configurations that use the Network Utility as a channel gateway to a mainframe system. Three of the samples show ESCON channel configurations and one shows a parallel channel. These configurations are:
All of these configurations can be built using either the Network Utility model TN1 or TX1. You do not need the extra function provided by the model TN1 unless you are planning to configure the TN3270E server function in the same machine.
This scenario is shown in Figure 14-4. The Network Utility is configured to support both SNA and IP traffic into the host from both remote sites and LAN segments at the main site. The ESCON channel adapter is configured with an LSA direct interface to transport the SNA traffic and an LCS interface to perform IP forwarding.
Figure 14-4. ESCON Channel Gateway
View figure.
The subchannel definitions for both the LCS and the LSA
interfaces must match parameters used in the host to define the Network
Utility to the host channel subsystem. The key subchannel parameters to
configure at the Network Utility are shown in Table 14-1.
Table 14-1. Network Utility Subchannel Configuration Parameters
| Command | Description |
|---|---|
| device | The unit address transmitted on the channel path to select the Network
Utility. It is also referred to as subchannel number in S/370 I/O
architecture. It is a two-digit hexadecimal value in the range 00 to
FF. This value is defined in the host Input/Output Configuration
Program (IOCP) by the UNITADD statement on the CNTLUNIT macro instruction for
the real device.
|
| cu | The Control Unit address defined in the host for the Network
Utility. This value is defined in the host IOCP by the CUADD statement
on the CNTLUNIT macro instruction.
|
| link | This parameter is significant when an IBM 9032 ESCON Director (ESCD) is
used between the Network Utility and the host. When an ESCD is used,
the link address is the port number of the ESCON Director (ESCD) to which the
host is attached. If two ESCDs are in the path, it is the
host-side port number of the ESCD defined with the dynamic connection.
When no ESCD is in the communication path, this value must be set to
X'01'.
|
| lpar |
Logical partition number. This allows multiple logical host partitions
to share one ESCON fiber. This value is defined in the host IOCP by the
RESOURCE macro instruction. If the host is not using ESCON Multiple
Image Facility (EMIF), use the default of 0 for the LPAR number.
|
When defining an LSA, LCS, or MPC+ interface on the Network Utility, you need to specify correct values for the CU and the LPAR parameters.
| Notes on the CU Parameter: |
The value for the CU needs to be set if you have multiple LPARs or multiple MVS or OS/390 images that need to access the Network Utility. If so, then you will need to create an interface definition (LSA, LCS, or MPC+) for each LPAR and each will use a different value for the CU parameter. Further, the value of the CU parameter should match the CUADD parameter in the CNTLUNIT macro of the IOCP definition. Previously, whenever a new LPAR (partition) was configured, a unique CU number had to be configured with it. With PTF01, the CU number and LPAR are independent for ESCON. You do not need a unique CU number for each LPAR number. this greatly increases user configuration flexibility and simplifies operation in large host systems. |
| Notes on the LPAR Parameter: |
The first issue is whether the host is partitioned into multiple logical partitions (LPARs). If it is not, then the LPAR parameter will be zero. If it is, then you will need a RESOURCE macro in the host Input/Output Configuration Program (IOCP) definitions that specify each partition by name and assign a numeric value to each. This numeric value is used when configuring the Network Utility for the LPAR parameter. The second issue is whether the channel path identifiers (CHPIDs) are shared between one or more LPARs19. If you are not using shared channels (or you do not have EMIF), then the value for the LPAR parameter will be 0. The maximum number of LPARs per ESCON adapter has increased from 32 to 64. In order to support this, we have increased the maximum number of subchannels per adapter from 32 to 64 and increased the maximum number of virtual nets per adapter from 16 to 32. This is a benefit for LSA protocol users who need to configure more than 32 LPARs. |
Figure 14-5 shows an example where the host is partitioned but the channel paths are not shared between the LPARs.
Figure 14-5. Host/Network Utility Parameter Relationships (Nonshared CHPIDs)
View figure.
If you are using EMIF on the host, then multiple LPARs can share the same CHPID to the Network Utility. In this case, you will still need two interfaces defined on the Network Utility and each will have a different value specified for the CU parameter. The other parameters can use the same values. Figure 14-6 shows an example where the host is partitioned and EMIF is used to allow both partitions to use the same CHPID.
Figure 14-6. Host/Network Utility Parameter Relationships (Shared Channels)
View figure.
Figure 14-7 shows how the configuration parameters for the Network Utility correlate to the host parameters for an LSA interface definition.
Figure 14-7. Host/Network Utility Parameter Relationships - LSA
View figure.
Notes:
See Chapter 18, "Sample Host Definitions" for more explanation and samples of host definitions for this interface type.
For a complete look at the configuration parameters needed for this scenario, see Table 13-2.
Defining an LCS interface creates a virtual LAN inside the Network Utility. There are two IP stations on this LAN: the Network Utility and the host. This LAN must be a unique IP subnet in the network. A MAC address is also needed for the LCS interface. After you create the LCS interface, do not forget to assign the IP address to this interface.
Network Utility provides three ways of operating the LCS interface:
The LCS support described above and documented in the example configurations is the initial 2216 LCS support released in MAS V1R1.1. This type of LCS support passes host IP traffic to the IP routing function within the Network Utility. If you are replacing a 3172 with a Network Utility configured with this type of LCS support, you need to configure an additional IP subnet for the virtual LAN segment inside the Network Utility.
MAS V3.2 introduces "LCS Bridging" (officially called "TCP/IP Passthru"), to enable 3172 replacement with no changes to the IP topology of the network. In this mode, the Network Utility simply bridges IP traffic between an LCS bridge port and other configured bridge ports. No IP routing is performed as frames are transferred from one port to another. To enable this mode, you do not specify an IP address for the LCS interface, but you do define a MAC address and enable bridging on it. See the MAS V3.2 Software User's Guide for more information on configuring this function.
MAS V3.2 PTF01 makes available a third type of LCS support, which can be called "3172 Emulation". This LCS mode mirrors 3172 behavior exactly by mapping an LCS virtual interface to a single LAN interface. Unlike LCS Bridging, where multiple paths exist between the various bridge-enabled interfaces, LCS Passthrough sets up independent fixed paths between specific subchannels and specific LAN adapters. Traffic on one path cannot be seen anywhere else. To enable this mode, you enable the 3172 emulation for this mode, you do not specify an IP address, and you reference a specific LAN adapter instead of defining an LCS MAC address by using the "NET" parameter when defining the LCS. By doing this, you pick up the LANtype and the MAC address of the LAN you are attaching to.
This channel gateway function allows the Network Utility to function as a drop-in 3172 replacement in TCP/IP networks. Frames received from a TCP/IP host are passed directly to a downstream LAN adapter, bypassing the IP router and bridging functions of the Network Utility. IP and ARP frames received by a LAN adapter associated with the LCS Passthrough function are passed directly to LCS for delivery to the TCP/IP host. The Network Utility replaces the 3172 LCS function without requiring changes in IP network topology or adding additional bridge hops, as previous LCS methods did.
Beginning with V3.2 PTF01, you can dynamically add a new ESCON virtual interface (LSA, MPC +, or LCS) using an LPAR that is not currently configured. Previously, a dynamically added net could only be configured with subchannels on an already configured LPAR. Adding an interface with a new LPAR logical path required disabling the entire physical channel interface. To use the new support, you configure spare interfaces, add the new virtual interface using "talk 6", and activate the new net using "talk 5".
This scenario is shown in Figure 14-8. It is identical to the ESCON channel gateway except that the connection to the host is via a S/370 Bus and Tag (Parallel Channel) Adapter instead of an ESCON channel. Like the ESCON gateway, this configuration uses an LSA direct connection for the SNA traffic and an LCS interface for the IP traffic.
Figure 14-8. Parallel Channel Gateway
View figure.
The configuration for this scenario is very similar to that for the ESCON gateway (see ESCON Channel Gateway). The configuration of the LSA and LCS interfaces require fewer parameters because no LPAR, Link Address, or Control Unit values are required for a bus and tag connection. The device address is still required to identify the Network Utility on the channel.
For a complete look at the configuration parameters needed for this scenario, see Figure 12-3. Also, Chapter 18, "Sample Host Definitions" contains a sample of the host IOCP definition for a Network Utility with a Parallel Channel Adapter.
This scenario is shown in Figure 14-9. Here, a Multi-Path Channel (MPC+) Group is used to transport both IP and APPN traffic between the Network Utility and the host. MPC+ uses a group of ESCON subchannels to maximize data transfer performance.
Figure 14-9. Channel Gateway (APPN and IP)
View figure.
The APPN traffic coming through the Network Utility is comprised of several different types from the routers in the remote branches:
In each of the above cases, the Network Utility is providing ANR forwarding only of the APPN traffic. 20 However, in addition to providing the ANR function, the Network Utility in this scenario could also be configured for TN3270E server support and DLUR support. The DLUR support could provide PU 2.0 devices on the local campus with access to the host and the TN3270E server could provide TN3270 support for workstations and printers on the local campus or for branches that do not have a distributed TN3270E server.
Note the following when configuring the Network Utility for this scenario:
Figure 14-10. Host/Network Utility Parameter Relationships - MPC+
View figure.
Notes:
See Chapter 18, "Sample Host Definitions" for examples of these host definitions.
In a single host environment it is not necessary to run a routing protocol (RIP, for example) on the ESCON subnet. In this case, it is sufficient to add the Network Utility as the default gateway in the host TCP/IP profile.
However, if there are multiple hosts or multiple Network Utility gateways, you should consider running RIP on the ESCON interface. Running a dynamic routing protocol in this environment allows you to route around network failures if an alternate path exists.
Network Utility supports both RIP V1 and V2. RIP V2 offers variable length subnets and other advanced features that RIP V1 does not, and is the recommended choice.
If you are running OSPF on your network, then you should import the ESCON subnet into OSPF (unless your host TCP/IP supports OSPF). If this is not done, only workstations connected directly to an interface on the Network Utility will be able to access the TCP/IP host on the ESCON interface.
For a complete look at the configuration parameters needed for this scenario, see Figure 12-8.
This scenario is shown in Figure 14-11. It utilizes redundant Network Utilities, each with an ESCON channel connection to the host. Also, the campus backbones have been duplexed and each Network Utility attaches to a different backbone.
With this configuration, you can still access the host even if you have a failure in one of the campus backbones or a Network Utility. The traffic coming in from the 2216s will still have a valid path to the host through one campus backbone and Network Utility. This is true for both IP and SNA traffic.
The ESCON Director (ESCD) is important in this configuration, especially in Parallel Sysplex environments, because it allows you to fully mesh the connections between the gateways and the LPARs in the sysplex. This provides the highest level of fault tolerance for host access.
Figure 14-11. ESCON Channel Gateway - High Availability
View figure.
The configuration for this scenario is very much like the one in ESCON Channel Gateway. Each Network Utility is configured as a LAN Channel Gateway with a separate LSA and LCS interface defined on each. See Table 13-2 for the parameters needed for configuring a Network Utility as a LAN Channel gateway.
Because each Network Utility is on a different Token Ring, the same MAC address can be used for the Token-Ring interface in each. The IP address used for each interface, however, must be different because each interface is on a different subnet.
| Note: | While this example shows the use of LSA and LCS connections on the ESCON channel, the use of MPC+ is equally effective in the high-availability environment. |
The configuration examples in this chapter and in DLSw LAN Channel Gateway show several different uses of channel DLCs:
An LCS Bridging interface appears to the bridge code as another LAN bridge port, and bridging performs its normal function to forward frames to other ports.
To manage the complete range of Network Utility gateway function, you need to manage IP, bridging, DLSw, and APPN as appropriate. This section does not cover these upper-layer functions, but focuses instead on the ways you can monitor and manage channel physical and virtual interfaces.
You access the talk 5 commands that show the status of channel resources hierarchically as follows:
The physical interface is commonly called the base net, and may have a number of LSA, LCS, or MPC+ virtual interfaces defined on top of it. The base net and all virtual interfaces each have a different logical interface number.
At these prompts, you can use the li nets command to see the current state of every (LSA, LCS, MPC+) virtual interface using this base net. You can also type li sub to view the currently running subchannel configuration for this base net.
Each of these prompts supports a list command, to show configuration and current status information relevant to the virtual interface type.
For examples and a detailed explanation of the output of these commands, see the chapter "Configuring and Monitoring the ESCON and Parallel Channel Adapters" in the MAS Software User's Guide.
Events occurring within the channel functions are covered by the following ELS subsystems:
To enable event logging, type event from talk 5 or talk 6 to reach the ELS Console or Config subprocess. If you want the logging output to go to talk 2, type disp sub subsystem name and press Enter to enable normal error reporting, or disp sub subsystem name all to enable all messages. To get the greatest visibility to a problem, you might enable both one of the ESCON or PCA subsystems, and one of the virtual interface subsystems. If you use these commands from talk 5, you can immediately move to talk 2 and monitor events as they occur.
You can get a feel for the events reported by each of these subsystems using the command li sub subsystem name from either the talk 5 or talk 6 ELS subprocess.
From a VTAM or NetView/390 operator console, you can control SNA resources associated with LSA direct gateway function, DLSw, or APPN as described in NetView/390.
The channel function itself does not send SNA alerts. It does not send traps that can be converted to alerts, but you can enable traps for channel ELS messages and use the products mentioned in IBM Nways Manager for AIX to convert those traps to alerts.
Network Utility supports an IBM enterprise-specific MIB for ESCON. This MIB provides access to the following information:
The ESCON MIB does not define any traps. Parallel channel functions have no MIB support.
Both ESCON and parallel channel interfaces are represented in the Interfaces MIB (RFC 1573), so a management station can access their status and basic per-interface traffic statistics. Network Utility allows a management station to control interface state, and can send traps to report when the interfaces go up or down.
The Network Utility Java-based application discussed in IBM Nways Manager Products provides integrated support for both the ESCON MIB and the Interfaces MIB. You can see color-coded interface status as well as specific panels that present key information from these MIBs. You can also use integrated browser support to view the information in either of these MIBs.
You can disable or enable the emission of interface up/down traps from the Nways Manager products.